The typical computer system includes at least one processor and a memory device. Executing on the computer system are various types of applications, such as operating system applications and user-level applications. Certain user-level applications, such as spreadsheets, databases, web pages, and tax applications are designed around the concept of forms. A form corresponds to any type of document (html page, spreadsheets, etc.) in which functionality is achieved through a combination of fields and calculations. A field in a form stores a data value, which may be supplied by the user (or other outside resource), or calculated using an equation. A user-generated field is a field whose data value is entered by the user or outside resource. A calculated field is a field in which the data value is obtained from evaluating an equation, typically deriving the data value from other user-generated fields and/or calculated fields. Note that it is possible for a field to be both user-generated and calculated.
Before forms can be populated with data, the set of fields and their equations must be specified in the design of the form. This design specification may be represented using a declarative programming language. The equations may include mathematical expressions, function calls, conditional expressions, etc. For example, if the equation for the field is the sum of the previous three fields (e.g., field—1, field—2, field—3), then associated with the field is typically an equation representing the summation (e.g., field—4=field—1+field—2+field—3 or field—4=sum(field—1, field—2, field—3)). The equations may be entered by the user (e.g., a user of a spreadsheet application) or by a programmer (e.g., a programmer of a spreadsheet application).
Often, the interdependencies in a form are complicated. Specifically, the interdependencies between fields and the equations used in different fields are often not intuitive to programmers or users. This may be especially the case in a declarative specification where there is no explicit flow of control that decides which order the equations are evaluated. Accordingly, in order to understand a form and how the values of the fields within a form are generated, programmers often rely on long static diagrams that are produced by individuals who design the application. The static diagram describes a theoretical control flow of the application. Specifically, the actual control flow may be different from the design if an error is in the application or if the programmer makes a change without updating the design. One method for a programmer to understand a form is to have the code translated from program code into a natural language. A translation corresponds to a word per function conversion from code into a natural language. For example, the expression x=y+z+b translates into the statement “x equals y added to z added to b.” Such translation allows a programmer to easily read complicated fields in a form in a familiar language.
In contrast to programmers who use static diagrams, users (e.g., users of a spreadsheet application) rely on static explanations that are produced by individuals writing the help files. The help files correspond to a snapshot of the description of the form at the time the form is created. The explanation found in the help files is static in nature. Specifically, the help file does not automatically change when the source code of an application is modified. Similarly, the explanations found in the help file remain static even when the forms that the help files are explaining are dynamic. When modifications are made to the form and a new version of the application is produced, each affected portion of a help file must be updated to ensure the help files are consistent with the form.